![[レポート]Dive deep on Amazon S3(AWS-01) #AWSSummit](https://devio2023-media.developers.io/wp-content/uploads/2024/06/eyecatch_awssummit2024_session.png)
[レポート]Dive deep on Amazon S3(AWS-01) #AWSSummit
2024.06.20こんにちは。たかやまです。
現在開催中のAWS Summit Japan 2024で行われた「Dive deep on Amazon S3」のレポートをお伝えします。
動画/資料も公開されましたので、ぜひご覧ください！
セッション概要
タイトル : Dive deep on Amazon S3
Amazon S3 は、業界トップクラスのスケーラビリティ、耐久性、セキュリティ、パフォーマンスを提供するクラウドオブジェクトストレージです。このセッションでは、Amazon S3 の基盤となるアーキテクチャを掘り下げ、どのようにしてスケーリングと伸縮自在性を実現しているのかを見ていきます。データ保護方法、データの耐久性に対する考え方や文化、そして新しい Amazon S3 Express One Zone ストレージクラスがどのように一貫したパフォーマンスを実現するかについて知っていただき、利用者の機械学習ワークロードや、データ分析を支える仕組みの理解を深めます。
スピーカー :
焼尾 徹セッションレベル : 300
レポート内容
目次
- Amazon S3 とは
- フロントエンドの理解
- インデックスの理解
- ストレージ層の理解
- Amazon S3 Express One Zone ストレージクラス
- 誤削除への対策
フロントエンドの理解
- ピークトラフィックは1PB/秒を超える
- ピークトラフィックへの緩和策として対応できる仕組み
- 並列にPut処理を行うマルチパートアップロード
- 一回の処理で送信する場合やりなしを行う必要がある
- マルチパートアップロードを行うことで、途中で失敗しても途中から再開できる
- 並列にGet処理を行うレンジリクエスト
- 同様にGet処理でもget-object-attributes/head-objectを利用することで並列処理が可能
- リクエストを複数のIPへ分散(フリートにわたってリクエスト分散させる)
- 複数のサーバにリクエストをする処理を行うことで処理を並列化する
- これら3つの仕組みは独自で検討することもできるがCRT(AWS Common Runtime)を利用することで仕組みを簡単に実装することができる
- Mountpoint for Amazon S3
- S3をマウント実装するのはいままではBatPracticeであった
- 現在もRest APIでS3を利用するのが一番快適なのは今もかわらない
- マウント処理はRest APIの処理をファイルマウント処理に解釈して利用するように裏ではCRTがよしなに動いている
- ユースケースとしては機械学習を想定
インデックスの理解
- S3は350兆のインデックスと1億/秒のリクエストを処理している
- S3はインデックス処理をオートスケールしている
- N-Sが英字的に多くなりがちなアルファベットで負荷が増えがち
- 負荷が増えるとN-P/Q-Sにアクセスを分散しオートスケールする
- ユーザ側でインデックス処理の負荷を減らす方法としてプレフィックスがある
- プレフィックスとはバケット名の後ろにつづく任意の文字列
- フォルダと呼ばれることもあるが、便宜上の表現でオブジェクト自体はフラットな構造である。
- プレフィックスキーがわかっていればどのファイルにも即時にアクセスできる
- プレフィックスあたりのアクセス性能
- 3,500 PUT リクエスト/秒
- 5,500 GET リクエスト/秒
- アクセス性能を超えるアクセスがくると503エラーがでてしまう
- 503エラー避けるために、プレフィックスの配置を工夫することができる
- 適切なキーの命名によるTPSの最大化
- キー名のカーディナリティ(都道府県とか)は左に寄せておく
- キー名に日付を入れるならばなるべく右に寄せておく
- もし日付を左によせているとday1とday2でパーティションが分かれることになりパーティションを効率よく使えない
- 人間的にはわかりにくいかもしれないが、システム的には右に寄せるのが理想
ストレージ層
- イレブンナインの耐久性
- デバイスの障害に対してどうやってイレブンナインの耐久性を実現するか
- リクエストの整合性のチェック(エンドツーエンドでの監査)
- 送信の際にチェックサムを取得する
- 保存時に送信時のチェックサムを比較することで整合性の担保を行う
- データは常に冗長化されているデバイスに格納される
- イレイジャーコーディングの仕組みでデータを冗長化している
- (今日この時間にもハードウェアは障害を起こしていても大丈夫なようになっている)
- 検査の仕組み
- AZ障害に対してどうやって耐久性を担保するのか
- S3はマルチAZがデフォルト
- すべてのAZに格納されてたことで200を返すようになっている
- ストレージクラス
- インテリジェントティアリングなどを利用することでうまく使いこなせる
- General purpose bucketはマルチAZ保存が基本
- Amazon S3 Express One Zone
- マルチAZ保存が基本の中で例外としてAmazon S3 Express One ZoneはシングルAZ
- ゆえにAZ障害を起こしたらデータ障害をおこす可能性がある
- なぜAmazon S3 Express One Zoneが生まれたか
- レイテンシを低減したいアプリケーションがある
- このニーズを叶えるためにAmazon S3 Express One Zoneがリリースされた
- One Zoneの2つの考慮事項
- AZへの配置によってネットワークレイテンシーに影響があること
- アプリケーションとOne Zoneは同じAZに配置することが理想
- One Zoneのストレージは異なる耐久性モデルとなること
- S3 Express One ZoneはS3 directory bucketという新しいバケットタイプ
- directory bucketははじめからスケーリングできるようになっており、プレフィックスの考慮は不要
- One Zoneのセキュリティモデル
- 従来のS3の認証認可の仕組みと異なり、一度認可が通ればそのあとの認証認可は行わないことで性能を上げている
- 最新のSDKを利用することでセキュリティの仕組みを透過的に利用できる
- 利用の想定者は機械学習などのI/Oが求められる人
- 学習ジョブのステレージ性能に与える影響要素
- 全体のデータセットサイズや全体のファイル数
- それぞれのファイルサイズ(大/小)
- データの取り込み(あらかじめコピーするのかオンデマンド処理をするのか)
- アクセスパターン(シーケンシャル/ランダム)
- ワークロードが高速化されるシナリオ
- ジョブ完了までStorageアクセスのレイテンシが多いパターン
- One Zoneを利用することでレイテンシを削減できる
- 機械学習でのS3 Express One Zone活用例
- SageMakerのトレーニングコードのデータ接続先にOne Zoneを利用する
- トレーニングジョブの時間を削減(かつGPUの性能をフルで利用)することでコンピュートリソースの利用料も削減できる
誤削除への対策
- 誤削除なのか明確な削除なのかシステムでは判断が難しい
- 誤削除への緩和策としての仕組み
- S3 Versioning
- S3 Replication
- S3 Object Lock
- AWS Backup
- ※上記の仕組みはS3 Express One Zoneでは提供していないのは注意が必要
最後に
本セッションを見ることで改めてS3というサービスの奥深さを知ることができました。
2018年のアップデートでプレフィックス周りの考慮はだいぶ減ったものの、3,500 PUTリクエスト/秒/5,500 GETリクエスト/秒 にせまるアクセスのユースケースがある場合にはプレフィックスの配置を工夫することで性能を最大化できることがわかりました。
また、昨今の生成AIニーズの高まりの中で、こういったプレフィックスのテクニックやAmazon S3 Express One Zoneの活用の機会は増えてくるのだろうと感じます！
以上、たかやま(@nyan_kotaroo)でした。
